home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-manning-dns-nsap-00.txt < prev    next >
Text File  |  1993-03-03  |  19KB  |  620 lines
  1.  
  2.  
  3. Network Working Group                 B. Manning (Rice University)
  4. INTERNET DRAFT                            R. Colella (NIST)
  5.                                  26 Nov, 1992
  6.  
  7.  
  8.  
  9.                              DNS NSAP RRs
  10.  
  11.  
  12.  
  13. Status of This Memo
  14.  
  15.  
  16. This memo refines the approch taken in RFC 1348, updating the processing
  17. methods for encoding of NSAP addresses for the Internet community. Discussion
  18. and suggestions for improvement are requested.
  19.  
  20. This document is an Internet Draft.  Internet Drafts are working documents of
  21. the Internet Engineering Task Force (IETF), its Areas, and its Working
  22. Groups. Note that other groups may also distribute working documents as
  23. Internet Drafts).
  24.  
  25. Internet Drafts are draft documents valid for a maximum of six months.
  26. Internet Drafts may be updated, replaced, or obsoleted by other documents at
  27. any time.  It is not appropriate to use Internet Drafts as reference material
  28. or to cite them other than as a "working draft" or "work in progress."
  29.  
  30. Please check the I-D abstract listing contained in each Internet Draft
  31. directory to learn the current status of this or any other Internet Draft.
  32.  
  33. It is intended that this document will be submitted to the IESG for
  34. consideration as a standards document.    Distribution of this document is
  35. unlimited.
  36.  
  37.  
  38.                                  Abstract
  39.  
  40.  
  41.  
  42. The Internet is moving towards the deployment of an OSI lower layers
  43. infrastructure.  This infrastructure comprises the connectionless network
  44. protocol (CLNP) and supporting routing protocols. Also required as part of
  45. this infrastructure is support in the DNS for mapping between names and NSAP
  46. addresses.
  47.  
  48.  
  49. This document redefines the format of two new Resource Records for the 
  50. Domain Name System, as defined in RFC 1348. This format may be used with 
  51. any OSI NSAP address format.
  52.  
  53. Expiration: April 14, 1993                    [Page 1]
  54.  
  55. INTERNET-DRAFT               DNS NSAP RRs            26 Nov, 1992
  56.  
  57.  
  58.  
  59. Contents
  60.  
  61.    1   Introduction  . . . . . . . . . . . . . . . . . . . . . . . 6
  62.    2   Background  . . . . . . . . . . . . . . . . . . . . . . . . 6
  63.    3   Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
  64.    4   Structure of NSAPs  . . . . . . . . . . . . . . . . . . . . 6
  65.    5   NSAP RR specification . . . . . . . . . . . . . . . . . . . 6
  66.    5.1 The NSAP RR . . . . . . . . . . . . . . . . . . . . . . . . 6
  67.    5.2 The NSAP-PTR RR . . . . . . . . . . . . . . . . . . . . . . 6
  68.    6   DNS Operation for NSAPs . . . . . . . . . . . . . . . . . . 6
  69.    7   Examples  . . . . . . . . . . . . . . . . . . . . . . . . . 6
  70.    8   Security  Considerations  . . . . . . . . . . . . . . . . . 6
  71.    9   References  . . . . . . . . . . . . . . . . . . . . . . . . 6
  72.    10  Author's Address  . . . . . . . . . . . . . . . . . . . . . 6
  73.    A   Issues  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
  74.  
  75.  
  76.  
  77. B. Manning (Rice University)                           [Page 2]
  78.  
  79. INTERNET-DRAFT               DNS NSAP RRs            26 Nov, 1992
  80.  
  81.  
  82.  
  83. 1   Introduction
  84.  
  85.  
  86.  
  87. The Internet is moving towards the deployment of an OSI lower layers
  88. infrastructure.  This infrastructure comprises the connectionless network
  89. protocol (CLNP) [ISO8473] and supporting routing protocols. Also required as
  90. part of this infrastructure is support in the Domain Name System (DNS)
  91. [RFC1034, RFC1035] for mapping between DNS names and OSI Network Service
  92. Access Point (NSAP) addresses [ISO8348Ad2] [Note: NSAP and NSAP address are
  93. used interchangeably throughout this memo].
  94.  
  95.  
  96. This memo redefines the format of two new Resource Records (RRs) for the DNS,
  97. as defined in RFC 1348. This format may be used with any OSI NSAP format.
  98.  
  99.  
  100. This memo assumes that the reader is familiar with the DNS. Some familiarity
  101. with NSAPs is useful; see [RFC1237] or [ISO8348Ad2] for additional
  102. information.
  103.  
  104.  
  105.  
  106. 2   Background
  107.  
  108.  
  109.  
  110. The reason for defining DNS mappings for NSAPs is to support CLNP in the
  111. Internet. Debugging with CLNP ping and traceroute is becoming more difficult
  112. with only numeric NSAPs as the scale of deployment increases. Current debugging
  113. is supported by maintaining and exchanging a configuration file with name/NSAP
  114. mappings similar in function to hosts.txt.  This suffers from the lack of a
  115. central coordinator for this file and also from the perspective of scaling.
  116. The former is the most serious short-term problem. Scaling of a hosts.txt-like
  117. solution has well-known long-term scaling difficiencies.
  118.  
  119.  
  120. A second reason for this work is the proposal to use CLNP as a replacement
  121. for IP: "TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for
  122. Internet Addressing and Routing" [RFC1347]. Should this proposal be selected,
  123. the DNS must be capable of supporting CLNP addresses.
  124.  
  125.  
  126.  
  127. 3   Scope
  128.  
  129.  
  130.  
  131. The RRs defined in this paper support all known NSAP formats. In addition,
  132. the RRs support the notion of a custom-defined NSAP format. There are several
  133. ways in which an NSAP can be defined. To illustrate this feature, examples in
  134. this memo will assume that the Internet obtained an AFI from ISO and defined
  135. a fixed-field NSAP format.
  136.  
  137.  
  138. As a point of reference, there is a distinction between registration and
  139. publication of addresses. For IP addresses, the IANA is the root registration
  140. authority and the DNS a publication method.  For NSAPs, ISO8348/Ad2 is the
  141. root registration authority and the DNS is being proposed as a publication
  142. method. 
  143.  
  144.  
  145.  
  146. B. Manning (Rice University)                         [Page 3]
  147.  
  148. INTERNET-DRAFT               DNS NSAP RRs            26 Nov, 1992
  149.  
  150.  
  151.  
  152. 4   Structure of NSAPs
  153.  
  154.  
  155.  
  156. NSAPs are hierarchically structured to allow distributed administration and
  157. efficient routing. Distributed administration permits subdelegated addressing
  158. authorities to, as allowed by the delegator, further structure the portion of
  159. the NSAP space under their delegated control. Accomodation of this
  160. distributed authority requires flexibility in the DNS representation of
  161. NSAPs, allowing sub- authorities to represent the substructure they define, if
  162. any, in the DNS as well as the NSAP values themselves.
  163.  
  164.  
  165. While all NSAP structures currently known to be in use in the Internet have
  166. fixed field sizes (e.g., [RFC1237, IPTAG-92-23-PB660], some NSAP formats
  167. defined in ISO 8348Ad2 define one of the fields as variable-sized. These
  168. formats are still parsable, since the total NSAP length is known and there
  169. is, at most, one variable-sized field. These formats are accomodated in this
  170. document, even though there is no current requirement. The notation is fully
  171. described in Section 5.2, "The NSAP_PTR RR" and the processing in Section 6,
  172. "DNS Operation for NSAPs."
  173.  
  174. For the purposes of this memo, NSAPs can be thought of as a tree of
  175. identifiers.  The root of the tree is defined in Addendum 2 to ISO8348
  176. [ISO8348Ad2], and has as its immediately registered subordinates the
  177. one-octet Authority and Format Identifiers (AFIs) defined there.  The size of
  178. subsequently-defined fields depends on which branch of the tree is taken. The
  179. depth of the tree varies according to the authority responsible for defining
  180. subsequent fields.
  181.  
  182.  
  183. An example is the authority under which US GOSIP defines NSAPs [GOSIPv2FT]. 
  184. Under the AFI of 47, NIST (National Institute of Standards and Technology)
  185. obtained a value of 0005 (the AFI of 47 defines the next field as being two
  186. octets consisting of four BCD digits from the International Code Designator
  187. space [ISO6523]). NIST defined the subsequent fields in [GOSIPv2FT].The field
  188. immediately following 0005 is a format identifier for the rest of the US
  189. GOSIP NSAP structure, with a hex value of 80. Following this is the
  190. three-octet field, values for which are allocated to network operators; the
  191. registration authority for this field is delegated to GSA (General Services
  192. Administration).
  193.  
  194.  
  195. The last octet of the NSAP is the NSelector (NSel). In practice, the NSAP
  196. minus the NSel identifies the CLNP protocol machine on a given system, and
  197. the NSel identifies the CLNP user. Since there can be more than on CLNP user
  198. (meaning multiple NSel values for a given "base" NSAP), the representation of
  199. the NSAP should be CLNP-user independent. TO achive this, an NSel value of
  200. zero will be used with all NSAP values stored in the DNS. An NSAP with NSel=0
  201. identifies the network layer itself. It is left to the application retrieving
  202. the NSAP to determine the appropriate value to use in that instance of
  203. communication.
  204.  
  205.  
  206. In the event that CLNP is used to support TCP and UDP services, the NSel
  207. value used will be the appropriate IP PROTO value as registered with IANA.
  208. For "standard" OSI, the selection of NSel values is left as a matter of local
  209. administration. Administrators of systems that support support TP0-4 in
  210. addition to TCP/UDP will select NSels for use by TP0-4 that do NOT conflict
  211. with the IP PROTO vlaues.
  212.  
  213.  
  214. For the purposes of this memo, we will present NSAPs as a string of
  215. "."-separated hex values. This is common usage, not the "+" operator
  216. specified in RFC1278. The values correspond to the fields in the NSAP, as
  217. defined by the appropriate authority. For example, a printable representation
  218. of the first four fields of a US GOSIP NSAP might look like
  219.  
  220.  
  221.  
  222.                              47.0005.80.005a00
  223.  
  224.  
  225.  
  226. and a full US GOSIP NSAP is
  227.  
  228.  
  229.  
  230.                 47.0005.80.005a00.0000.1000.0020.00800a123456.01.
  231.  
  232.  
  233.  
  234. For more information on US GOSIP NSAPs, see RFC1237 [RFC1237]. Other NSAP
  235. formats have different fields and field widths; see the examples in Section 7
  236. and also [IPTAG-92-23-PB660].
  237.  
  238.  
  239.  
  240. B. Manning (Rice University)                         [Page 4]
  241.  
  242. INTERNET-DRAFT               DNS NSAP RRs            26 Nov, 1992
  243.  
  244.  
  245.  
  246. 5   NSAP RRs Specification
  247.  
  248.  
  249.  
  250. 5.1  The NSAP RR
  251.  
  252.  
  253.  
  254. The NSAP RR is defined with mnemonic NSAP and type code 22 (decimal). The
  255. NSAP RR has the following format:
  256.  
  257.  
  258.  
  259.                     < owner> < ttl> < class> NSAP < rdata>
  260.  
  261.  
  262.  
  263. All fields are required.
  264.  
  265.  
  266. The < owner> is the DNS name for the system that is addressed by the NSAP in
  267. the < rdata> field (see below).
  268.  
  269.  
  270. The meaning of the < ttl> field is as specified in RFC1034.
  271.  
  272.  
  273. The format of the NSAP RR is class insensitive.
  274.  
  275.  
  276. The < rdata> is a complete NSAP address expressed in the dotted hexidecimal
  277. notation as described in Section 7.
  278.  
  279.  
  280. NSAP RR causes no additional section processing.
  281.  
  282.  
  283.  
  284. 5.2  the NSAP-PTR RR
  285.  
  286.  
  287.  
  288. The NSAP-PTR RR is defined with mnemonic NSAP-PTR and type code 23 (decimal).
  289. It's function is analogous to the PTR record used for IP addresses [RFC1035,
  290. RFC1103], although the details of how it operates are different. The NSAP-PTR
  291. RR has the following format:
  292.  
  293.  
  294.  
  295.                   < owner> < ttl> < class> NSAP-PTR < rdata>
  296.  
  297.  
  298.  
  299. All fields are required.
  300.  
  301.  
  302. The < owner> is a complete NSAP or an NSAP prefix. The octets of the NSAP are
  303. in reverse order, with the least significant octet on the left and the AFI octet
  304. on the right. The reversal is on an octet boundary. The dotted hexidecimal
  305. notation described in Section 7 is used to separate the NSAP fields.
  306.  
  307.  
  308. The meaning of the < ttl> field is as specified in RFC1034.
  309.  
  310.  
  311.  
  312. B. Manning (Rice University)                        [Page 5]
  313.  
  314. INTERNET-DRAFT               DNS NSAP RRs            26 Nov, 1992
  315.  
  316.  
  317.  
  318. The format of the NSAP-PTR RR is class insensitive.
  319.  
  320.  
  321. The < rdata> field consists of two subfields separated by one or more spaces
  322. or tabs. The first subfield is a DNS name that corresponds to the owner of this
  323. NSAP prefix. In the case of an incomplete NSAP (i.e., an NSAP prefix), this
  324. subfield must name the root with a single ".".
  325.  
  326.  
  327. The second subfield of < rdata> contains structure information for subsequent
  328. fields of the NSAP, to the extent that they are known at this level of the NSAP
  329. tree. Strictly speaking, only the size of the next field is required to
  330. navigate the DNS NSAP tree. However, for efficiency the NSAP structure
  331. information should be included as far up towards the root as possible.
  332.  
  333.  
  334. The format of this subfield is a set of "."-separated decimal digits
  335. representing the sizes of fields subsequent to the NSAP prefix given in the
  336. < owner> field. [Should we have a BNF for this?] A trailing "." indicates
  337. that the structure information is complete. For leaf entries (i.e., when the
  338. < owner> contains a complete NSAP), this subfield must contain a single ".".
  339.  
  340.  
  341. The NSAP-PTR RR causes no additional section processing.
  342.  
  343.  
  344.  
  345. 6   DNS Operation for NSAPs
  346.  
  347.  
  348.  
  349. Name-to-NSAP mapping in the DNS using the NSAP RR operates analogously to IP
  350. address lookup. A query
  351. is generated by the resolver requesting an NSAP RR for a provided DNS name.
  352.  
  353.  
  354. NSAP-to-name mapping using the NSAP-PTR RR differs from the inverse lookup
  355. for IP addresses due to the structure of NSAPs and the requirements this places
  356. on the lookup process.
  357.  
  358.  
  359. The NSAP-to-name scheme operates with minimal a priori knowledge of how NSAPs
  360. are structured and operates according to a simple algorithm. Given an NSAP to
  361. be resolved, the only a priori information needed is that the first field of
  362. all NSAPs is one octet. The basic algorithm operates as follows:
  363.  
  364.  
  365.  
  366. 1.build an initial query to read the record associated with the first octet.
  367.  
  368.  
  369. 2.knowledge of the NSAP structure is not complete, so set (COMPL-KNOW = FALSE).
  370.  
  371.  
  372. 3.send the query.
  373.  
  374.  
  375. 4.when the response is returned, if (COMPL-KNOW == TRUE), done.
  376.  
  377.  
  378. 5.construct a more detailed query with the additional structure information from
  379.    the response.
  380.  
  381.  
  382. 6.if the structure information returned in step 4 ends with a ".", then set
  383.    (COMPL-KNOW = TRUE).
  384.  
  385.  
  386.  
  387. B. Manning (Rice University)                         [Page 6]
  388.  
  389. INTERNET-DRAFT               DNS NSAP RRs            26 Nov, 1992
  390.  
  391.  
  392.  
  393.    7.go to step 3.
  394.  
  395.  
  396.  
  397. The a priori knowledge required is that all NSAPs begin with an initial
  398. one-octet field, the AFI (Authority and Format Identifier, see [ISO8348Ad2]);
  399. this is captured in step 1.
  400.  
  401.  
  402. Steps 3 through 7 represent a simple learning algorithm in which the resolver
  403. issues queries that are increasingly detailed until the result is obtained.
  404.  
  405.  
  406. Successful termination, step 4, occures if the last query sent was based on
  407. complete NSAP structure information, as determined by the trailing ".".
  408.  
  409.  
  410.  
  411. 7   Examples
  412.  
  413.  
  414.  
  415. Three examples are presented. The first uses US GOSIP NSAPs, the second a
  416. fictitious NSAP structure based on the idea of an Internet-assigned AFI, and the
  417. third demonstrates the scheme in the presence of a variable-length NSAP
  418. field.
  419.  
  420.  
  421.  
  422. ;;;;;;
  423. ;;;;;; GOSIP-style NSAP.
  424. ;;;;;;
  425.  
  426.  
  427. <owner>                 <class>    <type>    <rdata>
  428. .                          IN        NSAP      47
  429. .                          IN        NSAP      47.0005
  430. .                          IN        NSAP      47.0005.80
  431. nist.gov                  IN        NSAP      47.0005.80.005a00
  432. emu.ncsl.nist.gov        IN        NSAP      (
  433.                   47.0005.80.005a00.0000.1000.0020.00800a123456.01)
  434.  
  435.  
  436.  
  437. 47                        IN      NSAP-PTR    .  2
  438. 0500.47                   IN      NSAP-PTR    .  1
  439. 80.0500.47                IN      NSAP-PTR    .  3.2.2.2.6.1.
  440. 005a00.80.0500.47        IN      NSAP-PTR    nist.gov  2.2.2.6.1.
  441. 01.5634120a8000.2000.0010.0000.005a00.80.0500.47
  442.                            IN      NSAP-PTR    emu.ncsl.nist.gov  .)
  443.  
  444.  
  445.  
  446. ;;;;;;
  447. ;;;;;; Internet AFI-based NSAP.
  448. ;;;;;;
  449. ;
  450.  
  451.  
  452.  
  453. B. Manning (Rice University)                         [Page 7]
  454.  
  455. INTERNET-DRAFT               DNS NSAP RRs            26 Nov, 1992
  456.  
  457.  
  458.  
  459. ; Assume XX is the Internet AFI, and XX-based NSAPs have
  460. ; a fixed 19-byte format:
  461. ;         1.1.3.3.4.6.1.
  462. ; where the numbers indicate field sizes in octets.
  463. ;
  464.  
  465.  
  466. <owner>                 <class>    <type>    <rdata>
  467. .                          IN        NSAP      XX
  468. .                          IN        NSAP      XX.12
  469. bb                        IN        NSAP      XX.12.123456
  470. reg.bb                    IN        NSAP      XX.12.123456.151617
  471. host.reg.bb               IN        NSAP      (
  472.                   XX.12.123456.151617.37383930.414243454647.89)
  473.  
  474.  
  475.  
  476. XX                        IN      NSAP-PTR    .  1.3.3.4.6.1.
  477. 12.XX                     IN      NSAP-PTR    .  3.3.4.6.1.
  478. 563412.12.XX             IN      NSAP-PTR    bb  3.4.6.1.
  479. 171615.563412.12.XX      IN      NSAP-PTR    reg.bb  4.6.1.
  480. 89.474645434241.30393837.171615.563412.12.XX  (
  481.                            IN      NSAP-PTR    host.reg.bb  .)
  482.  
  483.  
  484.  
  485. ;;;;;;
  486. ;;;;;; NSAP with variable-size field.
  487. ;;;;;;
  488. ;
  489. ; An example of an NSAP format with a variable field size.
  490. ; The example is of an X.121 NSAP.
  491. ;
  492.  
  493.  
  494.  
  495. <owner>                 <class>    <type>    <rdata>
  496. .                          IN        NSAP     37
  497. one-org.com               IN        NSAP     37.31342023011007.01
  498. two-org.com               IN        NSAP     37.575654012456.03
  499.  
  500.  
  501. 37                        IN      NSAP-PTR  com  *.1.
  502. 01.07100123203431.37     IN      NSAP-PTR  one-org.com  .
  503. 03.562401545657.37       IN      NSAP-PTR  two-org.com  .
  504.  
  505.  
  506.  
  507. B. Manning (Rice University)                         [Page 8]
  508.  
  509. INTERNET-DRAFT               DNS NSAP RRs            26 Nov, 1992
  510.  
  511.  
  512.  
  513. 8   Security
  514.  
  515.  
  516.  
  517. Security issues are not addressed in this memo.
  518.  
  519.  
  520. 9   References
  521.  
  522.    [1] ISO/IEC, "Protocol for Providing the Connectionless-mode Network
  523.        Service"
  524.        USC/Information Sciences Institute, September 1981.
  525.  
  526.    [2] Reynolds, J., J. Postel, "Assigned Numbers", RFC 1340,
  527.        USC/Information Sciences Institute, July, 1992.
  528.  
  529.  
  530.  
  531. 10  Authors' Addresses
  532.  
  533.  
  534.  
  535. Bill Manning
  536. Rice University - ONCS
  537. P.O. Box 1892
  538. 6100 South Main
  539. Houston, Texas 77251-1892
  540. USA
  541.  
  542.  
  543. Phone: +1.713.285.5415
  544. EMail: bmanning@rice.edu
  545.  
  546.  
  547.  
  548. Richard Colella
  549. National Institute of Standards and Technology
  550. Technology/B217
  551. Gaithersburg, MD 20899
  552. USA
  553.  
  554.  
  555. Phone: +1 301-975-3627 (voice); +1 301 590-0932 (fax)
  556. EMail: colella@nist.gov (Internet)
  557. /C=us/A=attmail/P=gov+nist-gw/S=colella/ (X.400)
  558.  
  559.  
  560.  
  561. A   Issues
  562.  
  563.  
  564.  
  565. A.1  User Interfaces
  566.  
  567.  
  568.  
  569. Typical user interfaces, for example nslookup, expect the inverse map string
  570. to be typed from least significant byte to most significant byte followed by
  571. IN-ADDR.ARPA. This isn't too bad for four-byte IP addresses, but can be
  572. excruciating for 20-byte NSAPs. It would be much easier if this reversal
  573. could be done by the software instead of the user. This is especially true
  574. since one convenient way to handle NSAPs is by picking and stuffing values.
  575. So, if we have an NSAP,
  576.  
  577.  
  578.  
  579.                   47000580005a0000001000002000800a12345601
  580.  
  581.  
  582.  
  583. B. Manning (Rice University)                         [Page 9]
  584.  
  585. INTERNET-DRAFT               DNS NSAP RRs            26 Nov, 1992
  586.  
  587.  
  588.  
  589. One would like to pick it, stuff it on a command line (e.g., to nslookup),
  590. and append NSAP-PTR.ARPA.:
  591.  
  592.  
  593.  
  594.       % nslookup 47000580005a0000001000002000800a12345601.NSAP-PTR.ARPA.
  595.  
  596.  
  597.  
  598. The resolver code could recognize the NSAP-PTR.ARPA domain and perform the
  599. appropriate reversal before issuing the query.
  600.  
  601.  
  602. A.4  Relationship to X.500
  603.  
  604.  
  605. It may be useful to associate an X.500 distinguished name with an NSAP. Some
  606. thought should be given to whether this is useful and how it could be done.
  607.  
  608. A.5  NSAP prefixes
  609.  
  610. Should NSAP prefixes be encoded in the DNS? This may have some useful features.
  611.  
  612. Expiration: April 14, 1993                        [Page 10]
  613. B. Manning (Rice University)                        [Page 10]
  614.  
  615. -- 
  616. Regards,
  617. Bill Manning         bmanning@rice.edu        PO Box 1892
  618.  713-285-5415         713-527-6099           Houston, Texas
  619.    R.U. (o-kome)                           77251-1892
  620.